can you provide a traceback? (does the exception happen in your own code or somewhere within odxtools.)

The point with this is that using .short_name before references have been resolved will almost certainly lead to incorrect results, and IMVHO it is better to get an issue explicitly flagged by an exception than it is to introduce subtle bugs in the code...

can you provide a traceback? (does the exception happen in your own code or somewhere within odxtools.)

The point with this is that using .short_name before references have been resolved will almost certainly lead to incorrect results, and IMVHO it is better to get an issue explicitly flagged by an exception than it is to introduce subtle bugs in the code...

The traceback is already included (screenshot)

This PR just reverts the change from https://github.com/mercedes-benz/odxtools/pull/386/files#r1952936788 to unblock the situation. you can do a follow up PR with a more proper fix.

The traceback is already included (screenshot)

Yes, but I'm a bit confused: for me, loading a PDX file works fine using the current main version and the ecu variants in these files all specify quite a few comparams... (IOW, I would like to be able to replicate -- or at least understand -- the issue before reverting.)

@andlaus In

dlc._finalize_init(self, self._odxlinks) is called before dlc._resolve_snrefs(context), thus at that point of time spec has not been resolved yet, dlc._finalize_init creates the NamedItemList here

Creating the NamedItemList causes short_name getter to be called

I understand. What I don't get is why this is a problem: the spec_ref of the comparam_refs is exclusively resolved in _resolve_odxlinks() and ._resolve_odxlinks() is called before .finalize_init(). Also, why does it work fine for me but obviously not for @nada-ben-ali?